In computer networks such as the Internet, packets of data are sent from a source to a destination via a network of elements including links (communication paths such as telephone or optical lines) and nodes (for example, routers directing the packet along one or more of a plurality of links connected to it) according to one of various routing protocols.
One such protocol is MPLS (Multi Protocol Label Switching). MPLS is a protocol that is well known to the skilled reader and which is described in document “Multi Protocol Label Switching Architecture” which is available at the time of writing on the file “rfc3031.txt” in the directory “rfc” of the domain “ietf.org” on the World Wide Web. According to MPLS, a complete path for a source-destination pair is established, and values required for forwarding a packet between adjacent label switched routers (LSRs) in the path together with headers, or tags or “labels” are pre-pended to the packet. The labels are used to direct the packet to the correct interface and next hop. The labels precede the Internet Protocol (IP) or other header allowing smaller outer headers.
The path for the source-destination pair, termed a Label Switched Path (LSP) can be established according to various different approaches. One such approach is the Label Distribution Protocol (LDP) in which each router in the path invokes an LDP session with neighbouring LSRs and sends its label to the next hop router on the path as determined from its IP routing table. Alternative label distribution mechanisms include Resource Reservation Protocol (RSVP) in which case, for example, a network administrator can engineer a path, providing strict source routing and Border Gateway Protocol (BGP). In all cases a Label Forwarding Information Base (LFIB) stores both the next-hop information for the LSP, together with the label required by the next hop as a label binding.
For each LSP created, a forwarding equivalent class (FEC) is associated with the path specifying which packets are mapped to it.
At an ingress LSR to the LSP, packets destined, for example, for a certain destination or “prefix” are assigned to a corresponding FEC and injected into the LSP with the LSP next-hops ingress label pre-pended. The LSP next-hop router swaps its ingress label with an egress label received from its next-hop router and so forth. At an LSP egress router, the ingress label is removed and the packet is forwarded on towards the destination prefix according to the routing protocol supported thereafter.
One known use of MPLS is in MPLS virtual private networks (VPN) where an LSP is established between ingress and egress provider edge routers (PE) accessible by respective customer edge (CE) routers hence providing an effective tunnel between the customer edge routers.
MPLS VPN's are used for a range of telecommunications services but can give rise to difficulties in fault finding and troubleshooting. For example troubleshooting may be a manual task requiring complex procedures and hence costly skilled operators to find and diagnose faults. Both the isolation and identification of the cause of “broken” LSPs can hence lead to prolonged loss of connectivity for services using MPLS as a transport. Furthermore, problems tend to occur in ways that are not automatically detectable by the individual routers, such as misconfiguration or software/hardware defects such that customer intervention is required to draw the problem to the attention of the service provider.
Traditional fault management products focus on problem detection, alarm management and “trouble ticket” management. Problem detection is typically based upon receiving messages from network devices using simple network management protocol (SNMP) traps and logging messages, or polling the devices at regular intervals for predetermined fault symptoms. Alternatively test traffic can be injected into the network and problems detected in the form of an alarm. However other than generating a trouble ticket there is minimal support for subsequently diagnosing or troubleshooting the fault.
One known approach for detecting faults is described in “Detecting MPLS Data Plane Failures” of Kompella et al (“Kompella”) which is available at the time of writing on the file “draft-ietf-mpls-lsp-ping-03.txt” in the directory “proceedings/03jul/I-D” of the domain “ietf.org” of the World Wide Web. According to the approach described therein, in a first detection step a “LSP ping” command is sent followed by an “LSP traceroute command”. The LSP ping corresponds to an internet control message protocol (ICMP) ping comprising a packet sent along the path from the ingress point which is responded to from the egress point. Receipt of the response indicates that the path is healthy. LSP traceroute comprises a message which is received at each router along the LSP, passed along and responded to with additional diagnostic information. If there is a fault then the vicinity in which it occurred can be determined from identifying which furthest router sent a traceroute response. In addition the response itself may carry some low level diagnostic information. Accordingly the approach described in Kompella will tell a network administrator whether the path is healthy or broken and the general vicinity of any fault, but provides little more useful information.